Skip to content

Don't produce duplicate type definitions for recursive types #7524

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

mediremi
Copy link
Contributor

Before After
image image

Hover.expandTypes was creating duplicate entries for recursive types. By combining the type's env and name, I was able to create IDs for types and filter out those we've already seen.

@@ -115,7 +117,18 @@ let expandTypes ~file ~package ~supportsMarkdownLinks typ =
],
`InlineType )
| all ->
let typesSeen = ref StringSet.empty in
let typeId ~(env : QueryEnv.t) ~name =
env.file.moduleName :: List.rev (name :: env.pathRev) |> String.concat "."
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is based on Debug.debugPrintEnv

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's TypeUtils.findRootTypeId already, I wonder if that could cover this use case? It works on type_expr though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its full type is

TypeUtils.findRootTypeId ~(full : full) ~(env : QueryEnv.t) (t : Types.type_expr)

with type full = {extra: extra; file: File.t; package: package} and

type extra = {
  internalReferences: (int, Location.t list) Hashtbl.t;
  externalReferences:
    (string, (string list * Tip.t * Location.t) list) Hashtbl.t;
  fileReferences: (string, LocationSet.t) Hashtbl.t;
  mutable locItems: locItem list;
}

So my first question is would I need to build an extra value or would a dummy value like the following work?

{internalReferences: Hashtbl.empty, externalReferences: Hashtbl.empty, fileReferences: Hashtbl.empty, locItems: []}

As for getting type_expr values instead of Hover.extractedType values, I would need to modify Hover.findRelevantTypesFromType right? Or do you think I should be able to convert an extractedType to a type_expr?

type extractedType = {
  name: string;
  path: Path.t;
  decl: Types.type_declaration;
  env: SharedTypes.QueryEnv.t;
  loc: Warnings.loc;
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's stick with your current approach!

@mediremi mediremi marked this pull request as ready for review May 26, 2025 12:24
Copy link

pkg-pr-new bot commented May 26, 2025

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@7524

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7524

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7524

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7524

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7524

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7524

commit: d91d592

@mediremi
Copy link
Contributor Author

ping @zth

Copy link
Collaborator

@zth zth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff!

@zth zth merged commit 3853ddf into rescript-lang:master May 27, 2025
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants